Program Derivation Using Analogy

We present a methodology for using analogy to derive programs based on a derivational transformat ion method. The derived programs are deductively closed under the rules in the knowledge base, and the emphasis is on speeding up the derivation of a solution. We describe certain heuristics to find a good source analogue to the target problem efficiently, show how the derivation trace of that program can be used to guide the derivation of the new program. 1 I n t r o d u c t i o n Analogical reasoning is a mechanism for using past experience in solving a problem to solve a new, similar problem. Almost all the systems that perform analogical reasoning fal l under one of two broad categories. The first category of systems use analogy to solve a problem for which the domain theory is incomplete [Winston, 1980, Falkenhainer et a/., 1986, Greiner, 1988]. In such systems it would not be possible to solve the problem by a deductive mechanism, using only the known facts about the domain, and it is necessary to fill in the missing parts by analogy from a different situation or domain. The other category of systems use analogy to speed up the derivation of a solution. The final solution is deductively closed under the given domain theory, i.e. even wi thout analogy, it would have been possible to arrive at the solution. Such systems have mostly been used for theorem-proving and program construction [Kl ing, 1971, Dershowitz, 1983] though there are exceptions [Davies and Russel, 1987]. 1.1 U n i x P r o g r a m m i n g b y A n a l o g y The work presented here falls into the second category. It uses analogy to derive a program using past experience in solving a similar problem. The domain of programming is the Unix operating system environment. Unix programming is very similar to conventional programming. Its piping, sequencing, input-output redirection, shell control constructs, etc. are similar to the cont ro l structures available in high level programming languages. However, Unix has a much richer set of pr imit ive commands. These can be considered similar to a l ibrary of standard subroutines in conventional programming. Thus one works wi th a richer set of bui lding blocks than is available in general programming. 1.2 P r o b l e m Spec i f i ca t ion The system described here is designed to work on top of an automatic programming system which takes a semiformal specification of a problem and produces the correct sequence of Unix commands or a shell script to solve the problem. A problem specification in our system has the following form: INPUT: P r i m i t i v e o b j e c t s WHERE: SUCH-THAT:Constra in ts> OUTPUT: P r i m i t i v e f n ( a r g u m e n t s ) WHERE: SUCH-THAT: EFFECTS: P r i r a i t i v e f n ( a r g u m e n t s ) WHERE: SUCH-THAT: Here, I N P U T and O U T P U T specify the input and outputs of a program, and EFFECT specifies any sideeflfects that a program may have. The W H E R E slot describes the domains for the various fields, and SUCHT H A T specifies the constraints on the field values. For example, to specify a program that prints the name of all files greater than 10K and the owner of the file, the problem specification would be: INPUT: d i r WHERE: ( D i r e c t o r y d i r ) OUTPUT: ( L i s t f u) SUCH-THAT: (and (Belongs f d i r ) (> (S ize 1) 10K) (Owner u f) WHERE: (and ( F i l e f ) (User u ) ) In the above examples, Belongs, Owner, etc. are predefined predicates/functions and files, directories, users, etc. are pre-defined objects known to the system. In addit ion, it is possible for a user to define new relations, functions and objects and use them in a problem specification. For example a user may define an ANCESTOR function as : #DEFINE ances tor INPUT: f SUCH-THAT: (<> 1 / / ) WHERE: ( F i l e f) OUTPUT: (LIST d) SUCH-THAT:(= d (Un ion(Parent d) (Ances to r (Pa ren t d ) ) ) ) WHERE: ( D i r e c t o r y d) Harandi and Bhansali 389